rating: run integration conformance against the REAL migration DDL#27
Merged
Merged
Conversation
…on DDL The live-Postgres conformance test (TestIntegration_*/TestConformance_*) proved the rater's production SQL computes correct money — but against a hand-copied `schemaDDL` constant, not the migration that actually ships. The migration comments said "keep the two in sync"; that sync was enforced by a human reading two files. A column-type or index-expression drift between the copy and the migration would pass green here and break in prod — exactly the silent wrong-money failure this test exists to prevent. Replace the hand-copied constant with `ratingSchemaDDL(t)`, which loads the real migration files (migrations/0001_billing_event.sql then 0002_rating.sql, the production apply order — base_model is declared in 0001 and re-added IF NOT EXISTS in 0002_rating, a harmless overlap). The schema now CANNOT drift from production: if a migration changes, the conformance test runs against the new shape automatically. The old constant is retained, renamed `schemaDDLReference`, as a readable in-file description only (not applied — editing it edits a comment). The CI integration-test job (postgres:16 service, `make integration-test`) was already wired but tested a copy; it now tests the real schema on every PR. Verified: builds with -tags=integration, go vet clean, the full conformance suite passes against a throwaway postgres:16 loading the migration DDL, and the non-integration unit suite is unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
The live-Postgres conformance test (
TestIntegration_*/TestConformance_*) proves the rater's production SQL computes correct money — but it ran against a hand-copiedschemaDDLconstant, not the migration that ships. The sync between the two was enforced by a human reading two files. A column-type or index-expression drift between the copy and the migration would pass green here and break in prod — exactly the silent wrong-money failure this test exists to catch.Change
Replace the hand-copied constant with
ratingSchemaDDL(t), which loads the real migration files (migrations/0001_billing_event.sqlthen0002_rating.sql— production apply order;base_modelis declared in 0001 and re-addedIF NOT EXISTSin 0002_rating, a harmless overlap). The schema can no longer drift from production: a migration change is picked up by the conformance test automatically. The old constant is kept, renamedschemaDDLReference, as a readable in-file description only.The CI
integration-testjob (postgres:16 service) was already wired but tested a copy — it now tests the real schema on every PR.Verification
-tags=integration,go vetclean.Contracts
None. Test-only change — no schema, API, or behavior change. It tightens what the existing test validates against (a copy → the real migration).